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Abstract SOM (IBM’s System Object Model) removes a major impediment to reuse in Object-Oriented 
Programming by facilitating the programming of release-to-release binary compatible class libraries. This 
is accomplished by supporting a large number of compatibility preserving transformations. Taken together 
these transformations compose a discipline for programming evolving class libraries. 

The SOM Model 

In SOM [5,12,19], classes are objects whose 
classes are called metaclasses. A class is different 
from an ordinary object because a class has (in its 
instance data) an instance method table defining 
the methods to which instances of the class 
respond. During the initialization of a class object, 
a method is invoked on it that informs the class of 
its parents. This allows the class to build an initial 
instance method table. Once this is done, other 
methods are invoked on the class to override inher- 
ited methods or add new instance methods. 

When diagraming class hierarchies, this paper uses 
the convention that metaclasses are drawn with 
three concentric circles, ordinary classes (i.e., 
classes that are not metaclasses) are drawn with 
two concentric circles, and ordinary objects (i.e., 
objects that are not classes) are drawn with a single 
circle. The initial state of an example SOM pro- 
gram is depicted in Figure 1 . There arc four objects 
SOMObject (a class), SOMCIass (a metaclass), 
Dog (an ordinary class), and Rover (an ordinary 
object). There are two relations among objects that 
one must understand. 



Introduction 

The cover of the May, 1994 issue of Byte Maga- 
zine declared: “Object-oriented computing has 
failed.” However, Udel’s story inside [20] is not 
nearly as inflammatory. It describes the situation as 
we know it: despite all of its promise, software 
reuse in object-oriented programming has yet to 
reach its full potential. A major impediment to 
reuse is the inability to evolve a compiled class 
library without abandoning the support for the 
already compiled applications. The underlying 
cause of this problem is that the typical object-ori- 
ented model has elements that are not part of the 
interface model of the linkage editor/loader. There- 
fore, an object-oriented model must be carefully 
designed so that class-library transformations that 
should not break already compiled applications, 
indeed, do not break such applications. 

The System Object Model (SOM) is so designed. 
The next section gives an overview of SOM, after 
which we return to the problem of producing and 
supporting release-to-release binary compatible 
class libraries. This paper presents the SOM solu- 
tion to this problem. 
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Figure 1. Example of various SOM objects. 








First, there is the instance of relation between 
objects and classes depicted by the dashed arrow 
from an object to its class. When convenient the 
inverse relation, class of, is also used. SOMObject 
is an instance of SOMCIass and SOMCIass is the 
class of itself. An object’s class is important 
because an object responds only to the methods 
that are supported by its class (that is, the methods 
that the class introduces or inherits). 

Second, there is a relation between classes called 
the subclass of relation, which is depicted by the 
solid arrow from a class to each of its parents. 
SOMCIass is a subclass of SOMObject. SOMOb- 
ject has no parents. 

SOMObject introduces the methods to which all 
SOM objects respond. As a subclass of SOMOb- 
ject, SOMCIass is an object but in addition intro- 
duces the methods to which all classes respond. 
For example, SOMCIass introduces the somNew 
method, which creates instances of a class. Also, 



the methods responsible for creating and modify- 
ing instance method tables are introduced. All 
metaclasses in SOM are ultimately derived from 
SOMCIass. (Similar arrangements of classes are 
also usedinCLOS[ll,15], ObjVlisp[4j, Dylan|lJ, 
and Proteus[17].) SOMCIass and SOMObject are 
the two most important classes of the SOM kernel. 

Interfaces to SOM objects are described using IDL, 
an object interface definition language defined by 
the Common Object Request Broker Architecture 
(CORBA [13]) standard of the Object Manage- 
ment Group (OMG). SOM IDL is a CORBA-com- 
pliant version of IDL used to allow SOM class 
descriptions to be supplied in addition to object 
interface definitions. (That is, the interface to a 
class is described by the IDL alone, SOM IDL 
allows additional information about the implemen- 
tation to be added.) The SOMobjects Toolkit has 
tools called emitters that translate SOM IDL into 
language-specific bindings for the corresponding 
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classes of SOM objects (e.g., for C programmers 
this means that emitters produce header files for 
both the users of the class and the implementor of 
the class). 

Below is the basic structure of an 1DL definition 
for an object interface named Dog. At the same 
time, it is a SOM IDL description of a class Dog 
that supports this interface. The #if def and 
#endif (which, for simplicity, are omitted from 
subsequent examples) are part of the IDL language 
and are used to hide the SOM class implementation 
section from non-SOM IDL compilers. 

interface Dog : SOMObject { 

<method and attribute declarations here> 

#ifdef SOMIDL 

implementation { 
metaclass = SOMCiass; 



piled applications continue to run successfully. 

Let us consider the predicament of a software ven- 
dor that is selling a software library; the customers 
of the library vendor use the library to develop 
applications. The library vendor gives the custom- 
ers a description of the API to the library (e.g., 
header files or OMG IDL) and the compiled library 
in tlie form of a dynamically linked library (DLL). 
The interface to the (compiled) DLL is called the 
ABI. The advantage of using a DLL (to both the 
library vendor and the application producer) is that 
multiple applications may run with one copy of the 
DLL present, which vastly reduces the memory 
requirements and improves response time. This 
paper is aimed at one facet of flexibility of soft- 
ware; an excellent overview may be found in \2\. 



<instance variable declarations here> 

} ; 

#endif 

} ; 

In this example the interface Dog inherits from the 
SOMObject interface, and at the same time, the 
class Dog is declared to be a subclass of SOMOb- 
ject. CORBA and SOM support multiple inherit- 
ance; additional parents of Dog can be listed 
alongside SOMObject in a comma-separated list. 
The actual methods and instance variables of Dog 
are not relevant to the current discussion. As illus- 
trated here, the implementation section can explic- 
itly indicate a metaclass to be associated with the 
class of objects that support the interface being 
defined. This association is not necessarily direct, 
however. For reasons that will become clear, the 
actual class of the class described by any given 
SOM IDL is, in general, a subclass of the indicated 
metaclass. 
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Figure 2. A release-to-release binary compatible 
library revision supports compiled applications. 



A problem arises when the library vendor wishes 
to evolve the library (Figure 2). The library vendor 
must maintain release-to-release binary compati- 
bility, because it is impossible for the application 
producer to recompile file already distributed cop- 
ies of the application. 



The Library Compatibility Problem 

With SOM there is an important distinction 
between the term API (application programming 
interface) and ABI (applications binary interface). 
The API is the interface that a programmer uses, 
while the ABI refers to the specific conventions on 
which running programs depend. API compatibil- 
ity ensures that applications can be recompiled 
successfully; ABI compatibility ensures that com- 



The problem is couched in the terms of a library 
vendor, an application vendor, and dynamically 
linked libraries, because we wish to emphasize the 
relevance of our work to this area. In reality, the 
problem and our solution are much more general. 
The granularity goes down to the individual pro- 
grammer who provides libraries for others or even 
herself. Whenever a library is changed one must 
consider the impact on the applications that are 
already using the library. 
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Pragmatically, a revision to a library is release-to- 
release binary compatible if all the applications 
that depend on the library still work. Because of a 
lack of precise specifications for both the library 
and the application, this is a subjective judgement. 

For example, one can repair a defect in the library 
only to find that application programmers consider 
it a feature. 

Now this a bit abstract; let’s take as an example 
how C++ fails to support release-to-release binary 
compatibility. Figure 3 depicts the situation where 
class X (from the class library) is subclassed in the 
application with class Y. With release 1.0 of the 
library, the application runs perfectly; in particular, 
fmethod can be invoked on iY, an instance of class 
Y. Now let us consider what happens when the 
library vendor makes the seemingly innocuous 
change of adding a new method (hmethod) to 
class X, which is invoked from fmethod. Now 
because the application was built with the old 
library definition, the method table for Y has a 
pointer to gmethod in its second entry. However, 
when the fmethod is invoked on iY, it tries to sub- 
sequently invoke hmethod, which in class X is the 
second entry in the method table. The result is that 
gmethod is called when hmethod was specified. 

This situation is both familiar and frustrating to the The problems with this definition characterize the 

users of C++. What makes this problem even more difficulties of supporting the evolution of binary 

insidious is the fact that it appears that the problem class libraries. First, the operator QCj) symbol- 
is in class X, which is called the base class in C++. izes many different implementations (one for each 

Because of this example and others like it, the compiler/linker/loader combination). Second, there 

myth of the “fragile base class problem” has arisen. is no satisfactory definition of “reasonable func- 
The poor base class is blamed, diverting our atten- 



o 



Figure 3. An incompatibility produced by the typical C++ compiler. 





tion trom the real problem: the compiler/linker 
combination does not properly support subclassing 
across the binary interface. 

Defining Release-to-Release Binary 
Compatibility 

Creating an effective definition of release-to- 
release binary is not simple. Consider this direct 
attack on the problem. Let 

mean application A is combined to library L 
and let 

SAT( P, S ) 

mean program P satisfies specification S 

Straw-man Definition. L-| is a RRBC-successor to 
L-0 it 

SAT( A CID L 0 , S ) 
implies 

SAT(A ( ^D L^S) 

for all reasonable functional specifications S for all 
applications A using library L. 
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tional specification.” Third, establishing the impli- 
cation of lines 3 to 5 of the definition is tantamount 
to proving program equivalence, an unsolvable 
problem. Fourth, even if program equivalence 
were not unsolvable, defect removal implies some 
functions of the new library arc not equivalent. 
Fifth, even if “reasonable functional specification” 
could be satisfactorily defined, real software prod- 
ucts rarely have satisfactory formal specifications. 
Sixth, for a generally available class library prod- 
uct, one cannot know the set of applications using 
the library (this simply means that for generally 
available libraries, a successor must support all 
possible applications). 

In light of the above difficulties, the only recourse 
is to develop an engineering discipline for software 
libraries. This discipline should be based on trans- 
formations that are guaranteed to be compatibility 
preserving. This means that a library revision is 
compatible if only these transformations are used 
to derived it from the old library. The engineering 
discipline, then, requires a careful justification for 
those revisions that are not attained by the transfor- 
mations. 

The goal of this engineering discipline for com- 
piled libraries can be stated as: 

Only application alteration 

necessitates recompilation 

This implies that if the evolution of the class 
library does not require changes to the application 
source, then the application should not require 
recompilation. 

In terms of our straw-man definition, these trans- 



formation produce compatible RRBC-successors. 
But because the straw-man definition is not formal, 
each transformation must be independently justi- 
fied. In addition, enumerating the transformations 
of this discipline is not enough. Because compiled 
libraries must be accommodated, we must require 
that the technology for binding applications to 
libraries must support the transformations. Now as 
we shall see, for procedural programming, current 
linkage editors are adequate, but for object-ori- 
ented programming, SOM provides the most com- 
plete set of transformations. 

Procedural Programming 

For procedural programming (the style that pre- 
ceded object-oriented programming), the constitu- 
ents of an applications programming interface are 
procedures as depicted in Figure 4. Applications 
make procedure calls and linkage editors ensure 
that each procedure call is bound to the appropriate 
procedure implementation. 

With this ABI, the problem of release-to-release 
binary compatibility reduces to the question of: 

Is each procedure of the new library a more com- 
plete implementation of its predecessor? 

This implies that there are five transformations 
available to our engineering discipline: 

Transformation 0: 

The procedure can be reimplemented to 
provide better performance for the same 
functional interface. (Note that we ignore 
any pathological real-time situation where 
abetter performing implementation fails to 
meet its specification.) 




Figure 4. Procedure libraries evolve safely by adding new procedures. 
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Transformation 1 : 

The domain of the procedure can be 
enlarged to return values for inputs for 
which it previously aborted, failed to 
return (infinite loop or deadlock). 

Transformation 2: 

On systems where the calling conventions 
indicate the number of parameters, the 
number of parameters of a procedure can 
be increased. 

Transformation 3: 

Addition of new procedures. 

Transformation 4: 

Retraction of private procedures. 

Our engineering discipline says that as long as only 
these transformations are applied the new proce- 
dure library is an release-to-release binary compat- 
ible revision of the old library. Of course, there are 
good reasons for making changes that are outside 
these transformations; these must be carefully ana- 
lyzed for their impact on applications using the old 
libraries. 

Object-Oriented Programming 

The richness of Object-Oriented Programming 
adds new facets to the ABI. Besides the ABI of 
procedural libraries, OOP applications subclass the 
classes of the library (see Figure 5). The new 
aspects of the problem give rise to a new engineer- 
ing discipline needed to ensure release-to-rclease 
binary compatibility of a class library and thus, the 
continued functioning of the dependent applica- 
tions. 

Class Library 1,0 



The additional transformations required to support 
our engineering discipline are: 

Transformation 5 : 

Addition of new instance variables to 
objects 

Transformation 6: 

Addition of new methods to classes 
Transformation 7 : 

Insertion of new classes into the hierarchy 
Transformation 8: 

Migration of a parent class downward in 
the class hierarchy 

Transformation 9: 

Migration of a method upward in the class 
hierarchy 

Transformation 10: 

Retraction of private methods 

Transformation 1 1 : 

Retraction of private instance data 

Transformation 12: 

Reorder the methods of a class 

Transformation 13: 

Reorder the instance variables of an object 

Note that Transformation 8 is included in the list 
for completeness. It is attainable as a combination 
of Transformation 6 and Transformation 7. In addi- 
tion, it may seem counterintuitive that migration of 
a parent downward leaves the library compatible, 
but moving the parent downward just means that 
the new parents supports the functionality of the 
old parent. 

•; Class Library ^ 




Figure 5. Applications subclass from class libraries which evolve by adding new classes. 
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The need for these additional transformations is 
directly caused by permitting subclassing across 
the AB1. SOM is designed to support these addi- 
tional transformations. 

When classes are first class objects 

SOM allows and encourages the definition and 
explicit use of metaclasses. In this wider ABI, our 
engineering discipline requires an additional trans- 
formation. 

Transformation 14: 

The class of a class (i.e., its metaclass con- 
straint) can be moved downward in the 
class hierarchy. 

This transformation is similar to Transformation 8 
in that when migrating the metaclass downward 
the new metaclass supports all the functionality of 
the old metaclass. However, there is a constraint on 
the appropriateness of a new metaclass. 

Consider the simple single-inheritance example 
illustrated by Figure 6. In this figure, X is an 
instance of XMeta; we assume that XMeta supports 
a method bar and that X supports a method foo that 
uses the expression bar(class(self)). That is, the 
method foo invokes a method on the class of the 
object on which foo is operating. Now consider 
what happens when X is subclassed by Y, a class 
that has an explicit metaclass declared in its SOM 
1DL as in Figure 6. If the class hierarchy were to be 
formed as in Figure 6, then an invocation of foo on 
an instance of Y would fail because YMeta does not 
support bar. This situation is referred to the as 
metaclass incompatibility. 

SOM does not allow hierarchies with metaclass 
incompatibilities. Instead, SOM builds derived 
metaclasses that prevent this problem from occur- 
ring [6]. The actual SOM class hierarchy that 
results for Y is depicted in Figure 7, where SOM 
has automatically built the metaclass DerivedMeta- 
class; this ensures that the invocation of foo on 
instances of Y do not fail. This example shows that 
the metaclass statement in the SOM IDL is treated 
as a constraint on the actual metaclass. The derived 
metaclass can be viewed as the minimal metaclass 
supporting the constraints of metaclass compatibil- 
ity. 




interface X { 

void fool) ; 
implementation! 

metaclass = XMeta 
> ; 

} ; 

where 

foo ( ) 

{ . . . 

bar (class ( self ) ) ; 

. . . } ; 

interface Y:X { 

implementation! 
metaclass = YMeta 

Figure 6. Example of a metaclass incompatibility. 




Figure 7. Example of a derived metaclass. 
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Several papers [3,10] have called this situation the 
metaclass compatibility problem, but none go 
beyond a characterization of the compatibility con- 
dition required on the metaclass statement. In SOM 
there is no such problem; in a situation where the 
explicitly declared metaclass is not compatible 
with the parents of the class, an appropriate meta- 
class is constructed - this is the derived metaclass. 
Because class construction is a dynamic activity in 
SOM, this derivation is actually accomplished at 
runtime with no need for prior description in IDL. 

Now all languages have to solve the metaclass 
incompatibility problem. For example, C++ solves 
the problem by not having metaclasses. Smalltalk 
solves the problem by not allowing metaclasses to 
be explicitly named. CLOS has a rule for checking 
compatibility at class construction time that elimi- 
nations the possibility of a metaclass incompatibly 
(but failure of the check causes a runtime failure). 
Only SOM handle metaclass incompatibility with- 
out restricting the programmer. 

How Derived Metaclasses Support 
Binary Libraries 

SOM relieves programmers of the responsibility 
for getting the metaclass right when defining a new 
class. At first glance, this might seem to be merely 
a useful (though very important) convenience. But, 
in fact, it is essential to the support of release-to- 
release binary compatible libraries in SOM. 
Although a programmer might, at one time, know 
the metaclasses of all classes above a new subclass, 
and, as a result, be able to explicitly derive an 
appropriate metaclass for the new class, SOM must 
guarantee that this new class still executes cor- 
rectly when any of its ancestor class’s implementa- 
tions are changed (and this could include a choice 
of different metaclasses). Thus, a SOM program- 
mer never needs to consider a newly defined 
class’s ancestors’ metaclasses. Instead, explicit 
metaclasses should only be used to add in desired 
behavior for a new class. Anything else that is 
needed is done automatically [19]. 

Figure 8 contains a specific example. The applica- 
tion and the two libraries in the upper part of the 
diagram work correctly together. If the Library A 
evolves by inserting a new metaclass (which 
should be acceptable as it is moving the metaclass 



constraint downward), the metaclass incompatibil- 
ity depicted in Figure 6 is attained. 

Figure 9 shows how the lower half of Figure 8 
looks when built dynamically by the SOM kernel. 
This example makes one further point. The meta- 
class incompatibility can arise across libraries. 
There is no way for a metaclass programmer to 
know about how metaclasses are used in applica- 
tions. Without the notion of the derived metaclass, 
there is no way for the application programmer to 
avoid the situation. Yet it is very valuable to com- 
pose metaclasses as is shown in [8]. 

A comparison of support in several 
object models 

Now when choosing a programming system in 
which to produce compiled libraries one needs to 
consider which transformations are supported. 
Table 1 gives such a comparison for several object 
models 1 . The Smalltalk and C++ columns are 
generic, but the Delta/C++ refers to the C++ com- 
piler from Silicon Graphics [16,18] and OBI refers 
to the research work of Sun Microsystems [9], 

In Table 1 , %/ means the transformation is sup- 
ported and # means it is not. In the cases where the 
transformation has no meaning to that technology, 
Table 1 has an "n/a” entry. 

Note that none of these technologies (including 
SOM) support Transformation 2. This is not an 
impediment to evolving a class library, because 
one can define a new method (with a new name) 
having the expanded signature while retaining the 
old method. Now, the compiled applications run as 
expected while new applications use the new 
method. 



1. We exclude Microsoft's COM [14] because it is an 
interface model, not an object model and it’s AB1 
forbids subclassing between library and application. 
If our analysis technique is applied to COM, one 
sees that it supports only Transformations 0 to 4, 
which places it in the category of procedural pro- 
gramming rather than object-oriented programming. 
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Library B 1.0 



Library A 1.1 



YMeta 



XMeta 

5 ^=#'bar 



DerivedMetaclass 



Application 



Figure 8. Example of a meta- 
class incompatibility arising 
in library use. 



Figure 9. SOM prevents the 
Metaclass Incompatibility. 
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Table 1: Comparison of Support for Compiled Class Libraries 



Transformation 


Smalltalk 


Generic 

C++ 


SOM 


Delta/C++ 


OBI 


Objective- 

C 


0: improve performance 


✓ 


✓ 


✓ 


✓ 


✓ 


✓ 


1 : eliminate failures 


✓ 


✓ 


✓ 


✓ 


✓ 


✓ 


2: add parameter 


X 


x a 


mm 


X 


X 


X 


3: add procedure 


n/a 


✓ 


✓ 


✓ 


✓ 


✓ 


4: retract private 
procedure 


n/a 


✓ 


✓ 


✓ 


✓ 


✓ 


5: add instance variable 


mm 


X 


✓ 


✓ 


✓ 


X 


6: add new method 


✓ 


X 


✓ 


✓ 


✓ 


✓ 


7 : insert new class 


✓ 


X 


✓ 


✓ 


✓ 


X 


8: migrate parent 
downward 


✓ 


X 


✓ 


✓ 


x d 


X 


9: migrate method 
upward 


✓ 


X 


✓ 


✓ 


✓ 


✓ 


10: retract private 
method 


n/a 


X 


✓ 


m 


✓ 


n/a 


1 1 : retract private data 


n/a 


X 


✓ 


✓ 


✓ 


n/a 


12: reorder methods 


n/a 


X 


✓ 


✓ 




✓ 


13: reorder instance 
variables 


X 


X 


✓ 


✓ 


x d 


X f 


14: migrate metaclass 
constraint downward 


X 


n/a 


✓ 


n/a 


n/a 


X 



a. Because of overloading in C++, this box gets a formal It, because adding new parameters is defining a 
new method. One might think this is not a problem, because overloading allows multiple procedures with 
die same name. However, this causes an answer for procedures that is different than that for methods. 

b. However, SOM does support procedures and methods that are defined to have a variable number of 
parameters. 

c. With compiled Smalltalk, addition of instance variables requires recompilation of applications. 

d. One should bear in mind that OBI is a research project that had the additional goal of supporting multiple 
versions of a class. 

e. Because this is a C++ approach, one must ensure that private members that have not been exposed by 
friend specifications. 

f. Objcctivc-C supports direct access interface to instance data making this box It. Brad Cox informs us that 
wise Objective-C programmers avoid use of this facility (and by doing so, turn this box to a »/.) 
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Our presentation has been informal; e.g., we have 
not defined the criteria for a complete set of trans- 
formations that are compatibility preserving (for 
that matter, neither has compatibility preserving 
been formally defined). Usually lack of complete- 
ness of a transformation set implies lack of suffi- 
ciency. For the problem of evolution of class 
libraries, this is not the case. Clearly, SOM is not 
complete, because Transformation 2 is not sup- 
ported. But as we argue above, this is not a serious 
impediment to evolving a class library. 

Experience 

The SOM technology described here is more than a 
theory; it has been heavily used both within IBM 
and throughout the OS/2 development community 
for over three years. Numerous OS/2 applications 
and system facilities such as IBM’s LAN Server, 
MMPM/2, Ultimail, IBM Works, and even the OS/ 
2 Workplace Shell (the desktop user interface for 
OS/2) are built on the SOM technology. Even mod- 
erately-sized applications such as these contain 
dozens, and in some cases hundreds of SOM 
classes. These applications were developed inde- 
pendently and have evolved, even while SOM 
itself has been evolving. 

Figure 10 shows the progression of the SOM tech- 
nology and the OS/2 operating system. The debut 
of SOM 1.0 occurred in April 1992; it was an 
essential part of the first 32-bit OS/2 2.0 release. 
Although the 1 .0 level of SOM provided only a 
basic single-inheritance programming capability 
most of the RRBC features described in this paper 
were already present. In fact, it was the very pres- 



ence of the RRBC features in the early SOM that 
permitted the technology to evolve. 

The 2.0 level of SOM made a significant leap in 
terms of new features and new capabilities. This 
was the first attempt of any commercial product to 
embrace the fledgling CORBA 1.1 standard. For 
SOM this meant a new definition language for 
SOM interfaces, extensions to the base object 
model itself (such as multiple inheritance), and 
changes in the infrastructure to support distribution 
via an Object Request Broker (ORB), known as 
DSOM. Because the product cycles of the OS/2 
and SOM development teams were entirely inde- 
pendent, SOM 2.0 appeared in a separately 
licensed product called the SOMobjects Developer 
Toolkit. In addition to offering the basic SOM pro- 
gramming tools the toolkit also included a broad 
set of application frameworks and sample pro- 
grams. When installed on any OS/2 2.0 or 2.1 sys- 
tem, the SOM toolkit completely superceded the 
earlier level of SOM still found there. So. although 
none of the OS/2 SOM applications yet took 
advantage of the new features of SOM 2.0, all of 
the frameworks derived from SOM continued to 
work without recompilation, while newly devel- 
oped frameworks exploiting SOM 2.0 ran in the 
same environment. 

In October of 1994, SOMobjects Toolkit release 
2.1 became generally available; this release of 
SOM corrected some reported defects (the SOM 
developers are no more perfect or omniscient than 
anyone else) and added many performance 
enhancements. This time, the OS/2 Warp product 
cycle and the SOM product cycle coincided more 
favorably and the 2.1 level of SOM was included 




Figure 10. Evolution of SOMobjects Toolkit and the OS/2 Workplace Shell. 
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as an integral element of Warp. The most signifi- 
cant thing to note is that the OS/2 Warp Workplace 
Shell started its development (in Boca Raton. Flor- 
ida) using the SOM 2.0 kernel, while the SOM 
team in Austin, Texas, completed the 2.1 effort. 
Only late in the Warp development (July, 1994) did 
the Workplace Shell development team receive the 
new SOM 2.1 kernel. Because of SOM’s RRBC 
they were able to test without recompiling; allow- 
ing the SOM development team the independence 
of action necessary to fulfill its product require- 
ments without impacting the schedule of the of the 
Workplace Shell development team. 

This experience is only one of many similar expe- 
riences that might be cited as empirical proof of the 
efficacy of the SOM packaging technology. But the 
more fundamental point is that because of the 
RRBC emphasis in SOM such evolutionary devel- 
opment of independently shippable binary class 
libraries should be viewed as the norm. 

Many other groups are now recognizing the neces- 
sity of RRBC in the 00 marketplace. Because this 
capability is the sine qua non of independently 
developed component objects, SOM has been 
selected by Component Integrations Labs as the 
underlying mechanism for the OpenDoc frame- 
work. Other organizations believe it too. The Tool 
Integration Standards Committee (a group of vend- 
ers that create tools for Intel platforms, that 
includes IBM, Borland, Novel, Microsoft, 
Metaware, and others as members) in October, 
1994 agreed to adopt the SOM kernel and its ABI, 
as a standard solution for binary object interopera- 
bility and release-to-release binary compatibility. 

An Unsolved Problem 

When we began this work, we understood that the 
set of transformations implies a definition of “rea- 
sonable functional specification.” However, we 
have not yet discovered that definition from which 
the transformations would then be proved as com- 
patibility preserving. We would appreciate hearing 
from anyone who solves (or has solved) this prob- 
lem. 



Conclusion 

SOM facilitates the evolution of class libraries by 
supporting transformations that are compatibility 
preserving. These transformations form the foun- 
dation of an engineering discipline for class librar- 
ies. Although the transformation set is necessary 
for the discipline, we must still show that the set is 
sufficient for a library evolution. We have created 
numerous release-to-release binary compatible 
libraries cumulatively exercising all of the trans- 
formations. There is one library of special note. 
The SOM 2.0 DLL is release-to-release binary 
compatible with the SOM 1.0 DLL that is shipped 
with OS/2. That is. we practice what we preach — 
we have produced a nontrivial revision of a very 
complex library that is release-to-release binary 
compatible with its predecessor. 
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